-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Rust: Associated types are inherited as type parameters by traits and dyn traits #21165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
401495b to
a19ad5e
Compare
| override Location getLocation() { result = typeAlias.getLocation() } | ||
| } | ||
|
|
||
| /** Gets the associated type type parameter corresponding directly to `typeAlias`. */ |
Check warning
Code scanning / CodeQL
Comment has repeated word Warning
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, but it's the "associated-type" "type-parameter".
| result.isDirect() and result.getTypeAlias() = typeAlias | ||
| } | ||
|
|
||
| /** Gets the dyn type type parameter corresponding directly to `typeAlias`. */ |
Check warning
Code scanning / CodeQL
Comment has repeated word Warning
2215712 to
8cbe17a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR adds support for associated types from supertraits being inherited by subtraits and dyn traits as type parameters. The implementation treats these inherited associated types as type parameters to enable trait bounds and dyn types to specify values for associated types defined in supertraits.
Changes:
- Modified
TAssociatedTypeTypeParameterandTDynTraitTypeParameterto include the owning trait as a parameter - Added logic to propagate associated type parameters from supertraits to subtraits
- Updated type parameter sorting to account for the new trait parameter
- Reorganized test code by extracting associated type tests into a separate file
- Updated consistency checks to handle the new type parameter structure
Reviewed changes
Copilot reviewed 8 out of 9 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| rust/ql/lib/codeql/rust/internal/typeinference/Type.qll | Modified type parameter constructors to include trait parameter, added helper predicates for retrieving associated type parameters |
| rust/ql/lib/codeql/rust/internal/typeinference/TypeMention.qll | Updated type parameter resolution logic to handle inherited associated types from supertraits |
| rust/ql/lib/codeql/rust/internal/typeinference/TypeInference.qll | Updated type parameter ID calculation to include trait IDs for proper ordering |
| rust/ql/lib/codeql/rust/internal/typeinference/TypeInferenceConsistency.qll | Added check to ensure NonAliasPathTypeMention doesn't resolve to TypeAlias |
| rust/ql/lib/codeql/rust/elements/internal/TraitImpl.qll | Added getSupertrait() method to navigate trait hierarchy |
| rust/ql/test/library-tests/type-inference/main.rs | Removed associated type tests and added module reference to new file |
| rust/ql/test/library-tests/type-inference/associated_types.rs | New comprehensive test file for associated type scenarios |
| rust/ql/test/library-tests/type-inference/CONSISTENCY/PathResolutionConsistency.expected | Updated line number reference due to code reorganization |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| override ItemNode getDeclaringItem() { result = this.getTrait() } | ||
| /** | ||
| * Holds if this associated type type parameter corresponds directly its |
Copilot
AI
Jan 15, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Corrected grammar: 'corresponds directly its trait' should be 'corresponds directly to its trait'.
| * Holds if this associated type type parameter corresponds directly its | |
| * Holds if this associated type type parameter corresponds directly to its |
| name = result.getName().getText() | ||
| } | ||
|
|
||
| pragma[nomagic] |
Copilot
AI
Jan 15, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The method getAssocTypeArg is renamed from returning TypeRepr to returning TypeMention, but the name still suggests it returns a type argument. Consider renaming to getAssocTypeMention or updating the documentation to clarify the return type change.
| pragma[nomagic] | |
| pragma[nomagic] | |
| /** | |
| * Gets the associated type argument with the given `name` as a type mention. | |
| */ |
This is also how I envisioned it should be modeled 👍 |
This PR adds support for specifying associated type from a supertrait in a trait bound that uses a subtrait.
The Problem
Suppose we have a supertrait and a subtrait as follows:
Now trait bounds that use
AnotherGetcan mention theOutputassociated type like thisAdditionally,
dyntypes forAnotherGethave to specifyOutputfrom the supertrait:The Solution
To support the above, this PR makes associated types in supertraits (which are already turned into type parameters of the supertrait) induce type parameters in any subtraits (transitively). This seemed like the simplest implementation, given how we currently treat associated types as type parameters.
So in the above example, the trait
AnotherGetgets a type parameter forOutput, written asOutput[AnotherGet]. For a boundAnotherGet<Output = ..>the equality will instantiateOutput[AnotherGet].The new type parameters are accounted for in the sub-trait "inheritance" relation such that type parameters that correspond to the same associated type are matched up to each other.
Dyn trait types also receive the new type parameters in the same way as traits, such that
dyn Foostill has a set of type parameters that correspond 1-to-1 to those ofFoo.About the change to the consistency check:
Previously, for something like
the path
T::Outputwould inresolvePathTypeAtresolve to the type alias forOutputbut would then be filtered away insidePathTypeMention::resolvePathTypeAtat the check that prevents type parameters from escaping their scope.Now
resolvePathTypeAtwon't resolve to anything forT::OutputsinceTdoesn't resolve to a trait. This means that the current exemption doesn't apply and thus I added an additional one.Future Work
This should enable us to improve type inference for closures as well as support the
FnandFnMuttraits (which now inherits theResultassociated type from theirFnOncesupertrait).